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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Network sharing is a way for operators to share the heavy deployment costs for mobile networks, especially in the roll- 
out phase. In the current mobile telephony marketplace, functionality that enables various forms of network sharing is 
becoming more and more important. These aspects have not really been addressed in 3G systems, although there is 
functionality that supports a very basic type of network sharing in the current specifications within 3GPP. 

Scenarios and user requirements are described in TR 22.951 [1], while the current document presents the stage 2 details 
and descriptions of how these requirements are supported in a 3GPP network. 
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Scope 



The present document covers the details of Network Sharing. It shows how several core network operators can share 
one radio access network and details the impacts on the network architecture. All UEs shall comply with existing 
requirements, among them PLMN selection and system information reception. The present document defines additional 
requirements for network-sharing supporting UEs. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 22.951: "Service Aspects and Requirements for Network Sharing". 

[2] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[3] 3GPP TS 25.331: "RRC Protocol Specification". 

[4] 3GPP TS 23.122: "NAS Functions related to Mobile Station (MS) in idle mode". 

[5] 3GPP TS 32.250: "Telecommunication management; Charging management; Circuit Switched 

(CS) domain charging". 

[6] 3GPP TS 32.251: "Telecommunication management; Charging management; Packet Switched 

(PS) domain charging". 

[7] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[8] 3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple 

Core Network (CN) nodes". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definition below apply. Terms and definitions not 
defined below can be found in TR 21.905 [2]. 

Conventional network: A PLMN consisting of radio access network and core network, by which only one serving 
operator provides services to its subscriber. Subscribers of other operators may receive services by national or 
international roaming. 

Common PLMN: The PLMN-id indicated in the system broadcast information as defined for conventional networks, 
which non-supporting UEs understand as the serving operator. 

Core network operator: An operator that provides services to subscribers as one of multiple serving operators that 
share at least a radio access network. Each core network operator may provide services to subscriber of other operators 
by national or international roaming. 
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Gateway Core Network: A network sharing configuration in which parts of the core network (MSC/SGSNs) are also 
shared. 

Multi-Operator Core Network: A network-sharing configuration in which only the RAN is shared. 

Non-supporting UE: A UE that does not support network sharing in the sense that it ignores the additional broadcast 
system information that is specific for network sharing. In other specifications, the term "network sharing non- 
supporting UE" may be used. 

Supporting UE: A UE that supports network sharing in the sense that it is able to select a core network operator as the 
serving operator within a shared network. In other specifications, the term "network sharing supporting UE" may be 
used. 



3.2 



Void 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CN Core Network 

GWCN Gateway Core Network 

HLR Home Location Register 

MCC Mobile Country Code 

MNC Mobile Network Code 

MOCN Multi-Operator Core Network 

MSC Mobile Switching Centre 

PLMN PubUc Land Mobile Network 

RNC Radio Network Controller 

SGSN Serving GPRS Support Node 

TMSI Temporary Mobile Subscriber Identity 

UE User Equipment 

VLR Visitor Location Register 



General Description 



4.1 



Overview 



A network sharing architecture shall allow different core network operators to connect to a shared radio access network. 
The operators do not only share the radio network elements, but may also share the radio resources themselves. In 
addition to this shared radio access network the operators may or may not have additional dedicated radio access 
networks, like for example, 2G radio access networks. There are two identified architectures to be supported by network 
sharing. They are shown in the figures below. 

In both architectures, the radio access network is shared, figure 1 below shows reference architecture for network 
sharing in which also MSCs and SGSNs are shared. This configuration will be referred to as a Gateway Core Network 
(GWCN) configuration. 
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Figure 1 : A Gateway Core Network (GWCN) configuration for networit sharing. 
Besides shared radio access networit nodes, the core networit operators also 

share core network nodes 

Figure 2 below shows the reference architecture for network sharing in which only the radio access network is shared, 
the Multi-Operator Core Network (MOCN) configuration. 




RNC 



, Radio Access Network ,. 
'"■-.... Operator X -•■■ 



Figure 2: A Multi-Operator Core Network (MOCN) in which multiple CN nodes are 
connected to the same RNC and the CN nodes are operated by different operators 

The UE behaviour in both of these configurations shall be the same. No information concerning the configuration of a 
shared network shall be indicated to the UE. 

4.2 Core Network Operator and Network Selection 

Network sharing is an agreement between operators and shall be transparent to the user. This implies that a supporting 
UE needs to be able to discriminate between core network operators available in a shared radio access network and that 
these operators can be handled in the same way as operators in non-shared networks. 

4.2.1 Core network operator icJentity 

A core network operator is identified by a PLMN-id (MCCh-MNC). 

4.2.2 Broadcast system information for network sinaring 

Each cell in shared radio access network shall in the broadcast system information include information concerning 
available core network operators in the shared network. The available core network operators shall be the same for all 
cells of a Location Area in the shared network. A supporting UE decodes this information and take the information 
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concerning available core network operators into account in network and cell (re-)selection procedures. Broadcast 
system information is specified in TS 25.331 [3]. 

4.2.3 Network selection in a sinared networl< 

4.2.3.1 Behaviour of supporting UEs 

A supporting UE decodes the broadcast system information to determine available core network operators in the shared 
network. The UE regards both the core network operators indicated in the broadcast system information and 
conventional networks as individual networks. The core network operators together with all conventional networks are 
candidate PLMNs for the PLMN selection procedure that shall be performed by the UE as specified in TS 23. 122 [4]. A 
supporting UE shall not consider the common PLMN as a candidate for network selection. 

4.2.3.2 Behaviour of non-supporting UEs 

Non-supporting UEs ignore the broadcast system information that is relevant for network sharing. The common PLMN 
together with all conventional networks are candidate PLMNs for the PLMN selection procedure that shall be 
performed by the UE as specified in TS 23.122 [4]. 

4.2.4 Assignment of core network operator and core network node 

When a UE performs an initial access to a shared network, one of available CN operators shall be selected to serve the 
UE. For non-supporting UEs, the shared network selects an operator from the available CN operators. For supporting 
UEs, the selection of core network operator by the UE shall be respected by the network. Supporting UEs inform the 
RNC of the network of the identity of the chosen core network operator. In a GWCN configuration, the RNC relays this 
information to the shared core network node. 

In a MOCN configuration, the RAN routes the UE's initial access to the shared network to one of the available CN 
nodes. Supporting UEs shall inform the RAN of the chosen core network operator so that the RAN can route correctly. 
For non-supporting UEs the shared network selects an operator from the available CN operators. A redirection to 
another CN operator may be required for non-supporting UEs until an operator is found that can serve the UE. 
Redirection is described in subclause 7.1.4. 

After initial access to the shared network the UE does not change to another available CN operator as long as the 
selected CN operator is available to serve the UE's location. Only the network selection procedures specified in 
TS 23.122 [4] may cause a reselection of another available CN operator. Furthermore the UE does not change to 
another CN node as long as the selected CN node is available to serve the UE's location. 

When the network signals location (routing) area identities to supporting UEs, e.g. in location updating accept 
messages, these identities shall contain the chosen core network operator identity. For non-supporting UEs, they shall 
contain the common PLMN. The UE stores the received LAI/RAI on the SIM/USIM, as already specified in 
TS 24.008 [7]. 

4.2.5 PS and CS domain registration coordination 

In conventional networks, the same CN operator always serves the UE in CS and PS domains. In a shared network, 
supporting UEs shall behave as UEs in conventional networks with respect to registration with CS and PS domains. For 
non-supporting UEs, the Gs interface may be configured to guarantee that the same CN operator serves the subscriber in 
CS and PS domains. 

Alternatively, in networks not using Gs the RNC may for non-supporting UE's coordinate that the CS and PS 
registrations for a given subscriber are always sent to the same CN operator. In that case RNC based coordination of PS 
and CS domain registration is configured in CN nodes and RNC. When a CN node receives a registration from a 
subscriber with a non-supporting UE having a P-TMSI/TMSI not belonging to the pool, and no IMSI is provided by 
RNC, it returns a Reroute Command message to the RNC (according to subclause 7.1.4 "Non-supporting UEs in a 
MOCN configuration") for coordination purposes. The coordination is done in the RNC (without memorising IMSI 
information for IDLE mode UEs), e.g. uses a fixed split of IMSI ranges or IMSI hash table between operators. The 
coordination may result in that the registration is sent back to the same CN node or CN operator again. 

A network should not be configured to use RNC coordination when Gs interface is in use. 
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4.2.6 Attach/detach handling 

To attach to the same core network operator from which it detached, a UE uses information stored on the SIM/USIM. 
For a supporting UE in a shared network, the stored information indicates the core network operator it detached from 
(as specified in subclause 4.2.4). This information enables a supporting UE to attach to the same core network operator 
from which it detached. For non-supporting UEs in a shared network, the stored information indicates the common 
PLMN. 

4.3 Network Name Display for Supporting UEs 

A supporting UE shows the name of the PLMN -id it has registered with. In case of a shared network, it is the PLMN -id 
of the chosen core network operator. The name stored in the UE for the PLMN -id is displayed except when the network 
indicates to the UE a name to be displayed, as already specified for non-supporting UEs. 



4.4 HPLIVIN Support 



The use of a shared VLR/SGSN shall not result in service restrictions, e.g. roaming restrictions. Since a HLR derives 
whether the subscriber roams in H- or V-PLMN from the VLR/SGSN number, a shared VLR/SGSN in a GWCN shall 
be allocated one specific number from each supported HPLMN, i.e. a shared VLR/SGSN has multiple numbers. The 
VLR/SGSN number of a user's serving CN operator is used in signalling with the HLR. 



5 Functional description 

The new behaviours of network nodes needed in order to describe network sharing are described. 

5.1 UE functions 

A supporting UE selects the core network operator and provides the PLMN-id of this operator to the network for 
routing purposes. 

5.2 RNC functions 

Network sharing information, i.e. available core network operators in the shared network, shall be transmitted in 
broadcast system information. If system information is transmitted to a supporting UE in dedicated signalling, the RNC 
shall indicate the PLMN-id of the core network operator towards which the UE already has a signalling connection (if a 
PLMN-id is included in the signalling). If the UE is non-supporting, the RNC shall indicate the common PLMN (if a 
PLMN-id identity is included in the signalling) 

The RNC shall indicate the selected core network operator to the CN for supporting UEs when transferring initial layer 
3 signalling. The selected CN operator is (i) indicated by the UE in RRC signalling or (ii) known implicitly from an 
already existing signalling connection. For non-supporting UEs, the RNC shall not indicate any selected core network 
operator to the CN. 

In case of relocation to a GWCN or a MOCN: 

If the source RNC can determine a core network operator to be used in the target network based on available shared 
networks access control information, current PLMN in use, or similar information present in the node, the source RNC 
shall at relocation indicate that selected core network operator to the target core network node. 

5.3 IVISC functions 

When a UE accesses an MSC the first time, i.e. when there is no VLR entry for this UE, the MSC verifies whether the 
UE belongs to one of the operators sharing the MSC or their roaming partners. For that purposes the MSC derives the 
IMSI from another MSC/VLR or from the UE. The MSC determines a serving CN operator unless the old MSC/VLR or 
the UE have indicated a core network operator. The MSC/VLR shall also store the identity of the serving core network 
operator. 
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In case of a MOCN configuration, an MSC may not able to provide service to the UE. The UE may then have to be 
redirected to a MSC of another core network operator. The MSCA'LR that finally serves the UE assigns a NRI to the 
UE. This will allow the RAN to route any subsequent UE accesses the to the serving MSCA'LR. 

For supporting UEs, i.e. when a selected core network operator has been indicated to the MSC by the RNC, the MSC 
indicates the selected core network operator PLMN-id in the LAI signalled to the UE in dedicated signalling. 

In case of relocation to a GWCN or a MOCN: 

There is no functionality in the source MSC to select a target core network operator or to modify the target core 
network operator selected by the RNC. 

If the source MSC has the capability to indicate the core network operator selected by the source RNC to the 
target MSC, the source MSC shall forward the selected core network operator chosen by the source RNC to the 
target MSC, which relays this information unchanged to the target RNC so that the appropriate PLMN-id can be 
signalled to the UE in dedicated system information signalling, as described in subclause 5.2. 

If the source RNC did not have the capability to determine a core network operator, the target MSC selects a 
core network operator and indicates it to the Target RNC. 

5.4 SGSN functions 

When a UE accesses an SGSN the first time, i.e. when the UE is not yet known by the SGSN, the SGSN verifies 
whether the UE belongs to one of the operators sharing the SGSN or their roaming partners. For that purposes the 
SGSN derives the IMSI from another SGSN or from the UE. The SGSN determines a serving core network operator 
unless the old SGSN or the UE have indicated a core network operator. The SGSN shall also store the identity of the 
serving core network operator. 

In case of a MOCN configuration, a SGSN may not able to provide service to the UE. The UE may then have to be 
redirected to a SGSN of another core network operator. The SGSN that finally serves the UE assigns a NRI to the UE. 
This will allow the RAN to route any subsequent UE accesses the to the serving SGSN. 

For supporting UEs, i.e. when a selected core network operator has been indicated to the SGSN by the RNC, the SGSN 
indicates the selected core network operator PLMN-id in the LAI/RAI signalled to the UE in dedicated signalling. 

In case of relocation to a GWCN or a MOCN: 

There is no functionality in the source SGSN to select a target core network operator or to modify the target core 
network operator selected by the RNC. The source SGSN shall forward the selected core network operator 
chosen by the source RNC to the target SGSN. 

The target SGSN indicates the selected core network operator chosen by the source RNC to the target RNC so 
that the appropriate PLMN-id can be signalled to the UE in dedicated system information signalling, as 
described in subclause 5.2. 

- If the source RNC did not have the capability to determine a target core network operator, the target SGSN selects a 
core network operator and indicates it to the Target RNC. 



Charging and accounting aspects 



To support inter-operator accounting in a shared network, it shall be possible to distinguish the share of usage of the 
shared core network node(s) between the sharing partners. The identity of the core network operator is included in the 
CDR types as specified in TS 32.250 [5] (CS) and TS 32.251 [6] (GPRS). 
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7.1 



Example signalling flows 



Network selection 



Signalling flows for manual and automatic network selection in a shared network architecture for successful and 
unsuccessful registration attempts are presented. 

7.1 .2 Non-supporting UEs in a GWCN configuration 

This example shows network selection for a non- supporting UE towards the PS domain in a shared network. 



Non -supporting 
UE 



1. System information 



2. UE cannot decode network sharing 

information in system broadcast 

information. 



3. Network selection 
(Common PLMN is candidate) 



4. ATTACH FiEQUEST 



5. CN node determines whether the 
UE is allowed to attach. 



6. A^ACH ACCEPT/REJECT 



Figure 3: Network selection for a non-supporting UE in a shared network. 

1 . The UE reads the broadcast system information in the shared RAN. 

2. A non-supporting UE cannot decode the shared network information in the broadcast system information. The 
common PLMN is the only candidate to be considered together with other PLMNs for network selection. 

3. The UE performs network selection among available PLMNs. 

4. The UE sends an ATTACH REQUEST message to the network. 

5. The shared SGSN determines whether the UE is allowed to attach. 

6. The shared SGSN sends the appropriate ACCEPT/REJECT message back to the UE. 

7.1 .3 Supporting UEs in a GWCN configuration 

This example shows network selection for a supporting UE towards the PS domain in a shared network.. 
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Shared SGSN 



Supporting UE 



1 ■ System information 



2. UE decodes network stiaring 

information in system broadcast 

information. 



3. Network selection 



4. ATTACH HEQUEST 



5. CN node determines wfietfier tfie 
UE is allowed to attach. 



6. ATTACH ACCEPT/REJECT 



Figure 4: Network selection for a supporting UE in a shared network. 

1. The UE reads the broadcast system information in the shared RAN. 

2. A supporting UE decodes the shared network information and suppHes the available core network operator 
PLMN-ids as candidates to the PLMN selection procedure. The common PLMN is not given as a candidate for 
network selection. 

3. The UE performs network selection among available PLMNs. 

4. The UE sends an ATTACH REQUEST message to the network indicating the chosen core network operator. 

5. The shared SGSN determines whether the UE is allowed to attach. 

6. The shared SGSN sends the appropriate ACCEPT/REJECT message back to the UE. 

7.1 .4 Non-supporting UEs in a MOCN configuration 

An example of an information flow for redirection is shown below. In this example an attach request from a non- 
supporting UE is directed to three different CN operators. The first rejects since it has no roaming agreement with the 
subscribers Home PLMN. The second rejects because of a roaming restriction found in HLR. The third CN operator 
accepts and completes the attach request. The different "MSC/SGSNs" in the example below shall be seen as different 
CN operators. One specific CN operator may also have several pooled MSCs/SGSNs connected to the RNC if lu-flex is 
used. 
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Figure 5: Information flow for redirection. 

1) The RRC connection is established. 

2) RNC receives an Initial Direct Transfer from an UE. The RNC is configured to work in a Shared RAN MOCN, 
and therefore it forwards the NAS message in an Initial UE with an additional redirect attempt flag set. The flag 
indicates that the MSC/SGSN shall respond to the attach request with a Reroute Command or Reroute Complete 
message. Selection of CN node is based on NRI (valid or invalid) if present in IDNNS or by random selection. 
A redirect attempt flag could also simply be the fact that the Initial UE message does not include any selected 
PLMN-ID (later RAN3 decision), which a supporting UE would include. Redirect is never done for supporting 
UEs. 

3) The MSC/SGSN receives the Initial UE with the redirect attempt flag set. It then knows it shall answer with a 
Reroute Command or Reroute Complete message. Those new messages might also be extensions to the Direct 
Transfer message (later RAN3 decision). 

4) The MSC/SGSN needs the IMSI of the UE. It is retrieved either from old MSC / old SGSN or from the UE as in 
this example. By comparing the IMSI with the roaming agreements of the CN operator, the MSC/SGSN 
discovers that roaming is not allowed or that roaming is allowed but CS/PS coordination required. Attach 
procedure is aborted. 

5) A message is sent back to the RNC with two NAS messages, the attach reject message and the original attach 
request message received from the UE (alternatively the original NAS message may be stored in the RNC). The 
IMSI is also included in the message, plus a reject cause code to the RNC. The message should be a new 
RANAP message. Reroute Command. It might also be an extended Direct Transfer message (later RAN3 
decision). 

The signalling connection between RNC and MSC/SGSN A is released. The RNC selects a MSC/SGSN in the 
next step. The already tried MSC/SGSNs is stored in the RNC during the redirect procedure so that the same 
node is not selected twice. 
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6) The RNC sends a new Initial UE to the next selected MSC/SGSN with the original NAS attach request message 
(in case of CS/PS coordination the Initial UE may also be sent back to the first MSC/SGSN depending on the 
outcome of the coordination). Redirect attempt flag is set and IMSI shall also be included to avoid a second 
IMSI retrieval from UE or old MSC/SGSN and to indicate that PS/CS domain coordination has been done in 
RNC (if enabled in RNC). The MSC/SGSN receiving the message starts its attach procedure. 

7) MSC/SGSN B does in general support roaming for the HPLMN of the IMSI and hence authentication is done 
and RAN ciphering is established. 

8) MSC/SGSN B updates the HLR and receives subscriber data from HLR. 

9) The subscription data do not allow roaming (e.g. regional or 3G). MSC/SGSN B sends a Reroute Command 
message including the attach reject message, a reject cause code, the original attach request message 
(alternatively stored in the RNC), and the N(SD) (for MSC only). IMSI is included in Reroute Command 
message only if it was not included in the Initial UE received by the MSC/SGSN. 

The signalling connection between the RNC and the MSC/SGSN B is released. The RNC then selects a new 
MSC/SGSN as in step 5. 

10) The MSC/SGSN C receives an Initial UE (with the original NAS attach request message) with the redirect 
attempt flag is set, an IMSI, and N(SD) (if MSC). The MSC/SGSN C starts the attach procedure and uses 
provided information (IMSI and N(SD)). 

1 1) MSC/SGSN C does in general support roaming for the HPLMN of the IMSI and hence authentication is done 
and RAN ciphering is established. 

12)MSC/SGSN C updates the HLR and receives subscriber data from HLR. Subscriber data allows roaming, and 
the MSC/SGSN C completes the attach procedure. This includes the assignment of a new TMSI/P-TMSI with an 
NRI that can be used by RNC to route subsequent signalling between UE and correct MSC/SGSN (lu-flex 
functionality). The Update Location sent to HLR also triggers a Cancel Location sent to the MSC/SGSN B. 

13) A Reroute Complete message with the NAS Attach accept message is sent to RNC. By usage of a specific 

Reroute Complete message, the RNC knows that the redirect is finished and can both forward the NAS message 
to the UE and clean up any stored redirect data (it is a later RAN3 decision if an extension to the Direct Transfer 
message shall be used instead of a new message). 

14) The Attach Accept is forwarded to the UE. The UE stores the TMSI/P-TMSI with the lu-flex NRI to be used for 
future signalling, even after power off. This is existing functionality. 

15)UE responds with an Attach Complete message. 

If the RNC finds no more MSC/SGSN to redirect to after receiving a Reroute Command message, e.g. step 5 or step 9, 
it compares the cause code with cause codes from other Reroute Command messages it has earlier received for this UE. 
A cause code ranking is done and the "softest" cause code is chosen and the corresponding saved NAS attach reject 
message is returned to the UE. 

Each CN node that receives an Initial UE, shall run its own authentication procedure. This may in some rare situations 
cause the UE to be authenticated more than once, however the trust-model used is that one CN operator shall not trust 
an authentication done by another CN operator. This will of course not be an optimal usage of radio resources, but 
given the rare occurrence of this, the increased signalling should not be of any significance. 

During the redirect procedure the RNC keeps a timer, which corresponds to the UE timer of releasing the RR 
connection (20 seconds). If the RNC when receiving a Reroute Command message finds that there is not sufficient time 
for another redirect, further redirect attempts are stopped (for this attach request message). The UE will repeat its attach 
request four times (each time waiting 15 seconds before it re-establishes the RR connection for another try). 

7.1 .5 Supporting UEs in a MOCN configuration 

Supporting UEs can make use of the additional information in the broadcast system information. The signaling flow is 
shown in the figure below. 
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Figure 6: Network selection by a supporting UE in a lUIOCN. 

1 . The UE reads the broadcast system information in the shared RAN. 

2. A supporting UE decodes the shared network information and suppHes the available core network operator 
PLMN-ids as candidates to the PLMN selection procedure. The common PLMN is not given as a candidate for 
network selection. 

3. The UE performs network selection among available PLMNs. 

4. The UE sends an ATTACH REQUEST message to the network. It also indicates to the RNC the chosen core 
network operator. The RNC uses the routing information to determine which core network operator the message 
should be routed to and the ATTACH REQUEST message is sent to the core network operator chosen by the 
UE. 

5. The core network determines whether the UE is allowed to attach to the network. 

6. The shared core network node sends the appropriate ACCEPT/REJECT message back to the UE. In case of an 
ATTACH ACCEPT message, the core network assigns the UE an appropriate TMSI/P-TMSI so that this identity 
can be used for any further rerouting of messages by the RNC. 
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Annex A (informative): 

Network Resource Indicator (NRI) allocation examples 

This annex contains examples for NRI co-ordination in shared networks. 



A.1 NRI in shared networks 



The Network Resource Identifier (NRI) is specified in Rel-5 for Intra Domain Connection of RAN Nodes to Multiple 
CN nodes (see TS 23.236 [8]). NRI is part of the temporary indentity TMSI (CS domain) or P-TMSI (PS domain), 
which is assigned by the serving CN node to the MS. 

Within the shared network NRIs has to be coordinated between the operators at least due to following reasons: 

to avoid redirection when the non-supporting UE performs LA/RA update. 

to guarantee that correct UE answers to paging (TMSI/P-TMSI shall be unique within shared network). 

to guarantee that a non-supporting UE in visited PLMN will not change network due LA/RA update or 
Detach/ Attach function. 

NRI coordination is also required between the shared network and the dedicated networks of the sharing partners: 

to guarantee that non-supporting UE in visited PLMN remain registered in the same operators network when the 
UE moves from dedicated network to a shared network. 

to avoid redirection when the non-supporting UE in home PLMN performs LA/RA update from dedicated 
network to a shared network. 

In figure A. 1 below operators A, B and C have both shared and dedicated networks, operator D has only dedicated 
network and operator E only shared network. 




Figure A.1 : Shared and Dedicated network example 

In the above, one or more of the operators in the shared network may deploy lu-Flex between that shared radio access 
network and their core networks. Additionally, operators may deploy lu-Flex within their dedicated core networks. For 
non-supporting UEs, NRI coordination is needed not only within the shared network, but also between the shared 
network and the dedicated networks. 
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A.2 Alternatives for NRI split 

Sharing operators need to coordinate the used NRI, following alternatives are considered: 

1) even split of NRI space, 1 . . .3 most significant bits of NRI is used to identify the CN operator. 

2) individual NRI values used to identify the CN operator. 
Alternative 1; even split of NRI space 
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A calculation for the possible number of subscribers in this scenario is: 

With max 4 sharing CN operators, two most significant bits of NRI is required to identify the CN operator. 

3 bits are used for the restart counter. 

5 bits of NRI allows 32 independent NRI values for each CN operator. 

This leaves 20 bits for every MSC that is 1 M non-purged TMSI. 

The following aspects need to be considered for this solution: 

If more bits are needed for the restart counter or CN operator ID, each additional bit reduces the available TMSI 
space half. 

The basic configuration allows 32 M TMSI values for each CN operator, a lot of TMSI values are wasted if 
some sharing partners have substantially less subscribers than others. 

It may not be feasible in large networks that use lu-Flex for load balancing (see Annex A, network configuration 
examples in TS 23.236 [8]). 

The number of NRI bits used for CN operator ID may need to be fixed in the initial planning. Otherwise 
configuration of all existing nodes must be changed when new partners join the shared network. 

Alternative 2; individual NRI values used to identify the CN operator 

This could be considered in the case where a network is shared between one big and many small CN operators. 
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The biggest CN operator who needs more pool areas and TMSI space takes NRI values 32. . .63, [Ixxxxx], this 
means 32M TMSI values when 4 bit is used for restart counter. 

Rest of shared NRI space is allocated to other CN operators in blocks of 4M TMSI values like NRI = 28 - 3 1 
[0111 xx] ,24-27 [Oil Oxx] .... 0-3 [OOOxx] . Initially gaps can be left between allocated NRI range that can be 
used for expansion. 

Following aspects need to be considered for this solution: 

If more bits are needed for the restart counter or NRI, each additional bit reduces the available TMSI space half. 

The initial planning of NRI length should take into account the pool area configurations of all sharing operators. 

TMSI per LA: 

Taking the example configurations mentioned above but changing the TMSI allocation per LA would result in an 
increase of the addressing space, then the same TMSI value can be used multiple times in the same VLR. More 
considerations with this TMSI per LA approach can be found in TS 23.236 [8]. 
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